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ABSTRACT 

Flight and mission-critical systems are veri- 
fied, qualified for flight, and validated using well- 
known and well-established techniques. These 
techniques define the validation methodology used 
for such systems. In order to verify, qualify, 
and validate knowledge- based systems (KBSs), 
the methodology used for conventional systems 
must be addressed, and the applicability and limi- 
tations of that methodology to KBSs must be iden- 
tified. The author presents an outline of how this 
approach to the validation of KBSs is being de- 
veloped and used at the Dryden Flight Research 
Facility of the NASA Ames Research Center. 

1 INTRODUCTION 

The verification and validation (V&V) of 
flight-critical systems is a major activity at the 
Dryden Flight Research Facility of the NASA 
Ames Research Center (Ames-Dryden). The 
Ames-Dryden staff assumes safety-of-flight re- 
sponsibilities for all vehicles flown at the facility. 
Because these systems are used in research air- 
craft, the V&V experience at Ames-Dryden is pri- 
marily with one-of-a-kind research systems on ex- 
perimental vehicles. While the range of this expe- 
rience at Ames-Dryden is somewhat more narrow 
than that of the validation of flight-critical sys- 
tems for commercial operations [1], this experience 
is directly applicable to the types of knowledge- 
based systems (KBSs) within NASA research pro- 
grams, whose requirements are to qualify and val- 
idate unique, one-of-a-kind research systems. 

The Ames-Dryden V&V methodology for em- 
bedded flight-critical systems relies on testing, 


peer review, abstract models, simulations, and 
flight validation. This methodology also relies, in 
large part, on engineering judgment and a tradi- 
tion that has evolved from the experience with 
flight-critical systems from the first simplex dig- 
ital aircraft flight control system on the F-8 dig- 
ital fly- by- wire (DFBW) aircraft [2], through the 
triplex DFBW system on the F-8 aircraft [3,4], 
the 3/8th scale F-15 remotely piloted research ve- 
hicle (RPRV) [5], the highly maneuverable air- 
craft technology (HiMAT) vehicle [6, 7,8,9], and 
the advanced fighter technology integration pro- 
gram AFTI/F-16 [10,11], to the X-29 forward- 
swept wing aircraft. The result of this evolving, 
hands-on development of qualification and V&V 
methodologies is a practical approach that maxi- 
mizes safety and allows system qualification, verifi- 
cation, and validation to proceed in an expeditious 
and resource- effective manner. 

The V&V methodology used at Ames-Dryden 
is the same methodology that has actually been 
used for all flight-critical control systems in non- 
commercial aeronautical flight vehicles, including 
the lf-18, Space Shuttle, and B-l aircraft. This 
methodology uses a subset of the V&V techniques 
in use or advocated within the aeronautics com- 
munity. The larger issues of certification and 
the validation of highly reliable, fault- tolerant 
systems have been of lesser concern than those 
of qualifying and conducting flight validation of 
flight-critical systems. 

The basic methodology for the V&V of con- 
ventional operation-critical systems is directly ap- 
plicable to the V&V of KBSs. In fact, if KBSs 
are to be used in operation-critical applications, 
the qualification of these KBSs will have to be 
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performed within the context of established pro- 
cedures and will have to address the require- 
ments placed upon the qualification of conven- 
tional operation- critical systems. Thus, it is essen- 
tial that the main features of this well-established 
V&V methodology be understood. 

NOMENCLATURE 

a n normal acceleration, g 

h altitude, ft 

h, altitude rate, ft /sec 

h altitude acceleration, ft/sec 2 

f(h) functional relationship between h and a n 
K a aerodynamic gain 

Kq proportional path gain 

Kj integral path gain 

S Cx equivalent longitudinal stick command 

Ah difference between desired and actual 

altitude 

i representation of integrator in Laplace 

variable notation 


Abbreviations and Acronyms 

AFSR 

airworthiness and flight safety 
review 

AFTI 

advanced fighter technology 
integration 

AI 

artificial intelligence 

Ames-Dryden 

Dryden Flight Research Facility 
of the NASA Ames Research 
Center 

CCB 

configuration control board 

CCR 

configuration change request 

CDR 

critical design review 

DFBW 

digital fly-by-wire 

DR 

discrepancy report 

FRR 

flight readiness review 

HiMAT 

highly maneuverable aircraft 
technology 

KBS 

knowledge-based system 

PC 

program change (software) 

PDR 

preliminary design review 

RPRV 

remotely piloted research 
vehicle 

QA 

quality assurance 

SDR 

system design review 


STR system test report 

V&V verification and validation 

WO work order (hardware) 


Definitions 

The majority of the following definitions is 
taken verbatim from Szalai and others [4]. 
certification The determination by a regula- 
tory authority that a product meets the regula- 
tions for that product. 

embedded system A system that is an inte- 
gral part of some larger system. This distinction 
is particularly important when a subsystem inter- 
acts with the larger system in such a way that a 
failure in the embedded system can propagate to 
the larger system or cause the larger system to fail, 
fault tolerant A system which is able to con- 
tinue to provide critical functions after the occur- 
rence of a fault. 

flight critical A component or system whose 
failure could cause loss of the aircraft. 

mission critical A component or system 
whose failure could result in the inability to per- 
form a mission. 

operation critical A component or system 
whose failure could result in loss of the aircraft, 
loss of life or limb, compromise public safety, result 
in substantial financial loss, or inability to perform 
a mission. 

qualification A formal process whereby a sys- 
tem or aircraft is defined to be ready for flight 
operations. 

system An entity of fixed identity united by 
some form of purpose, interaction, or interdepen- 
dence that can be meaningfully isolated, 
validation The determination that a result- 
ing product meets the objectives that led to the 
specification for the product. This determination 
usually includes operation in a real environment, 
verification The determination that a design 
meets the specification. Verification is usually a 
part of the validation process. A simulated envi- 
ronment is often used. 
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2 A METHODOLOGY FOR 
CONVENTIONAL, 
EMBEDDED 
FLIGHT-CRITICAL 
CONTROL SYSTEMS 

The basis of the Ames- Dry den flight qualifi- 
cation and V&V methodology for embedded flight- 
critical systems is the incremental verification of 
system components, integration testing, configu- 
ration management, and flight validation. The 
application of the verification, integration testing, 
and flight validation is discussed within the overall 
context of the system life cycle. The configuration 
management aspect of the qualification and V&V 
methodology is discussed separately. 

2.1 Verification, Validation, and the 
System Life Cycle 

Verification and validation is an ongoing pro- 
cess that is an integral part of the system life cycle. 
The system life cycle for conventional flight con- 
trol systems is often characterized as a series of 
stages (figure 1). 

When functional specifications are derived 
from the system goals and requirements, those 
specifications must be critically examined to es- 
tablish that the specifications adequately address 
the system goals and requirements. Similarly, 
the design specifications must meet the functional 
specifications. This critical examination is accom- 


plished by system design reviews (SDRs), prelim- 
inary design reviews (PDRs), and critical design 
reviews (CDRs). The SDR is a presentation and 
review of the conceptual design of the system; the 
goals and requirements are addressed and top-level 
definition of functional specifications are provided. 
The purpose of the SDR is to ensure that the un- 
derstanding of the goals and requirements for the 
system is consistent between the requesters and 
designers. The PDR is a presentation of a first- 
order definition of the system design including a 
presentation of how the functional specifications 
are being addressed in the design. The CDR is a 
detailed design review in which a functioned design 
is presented for review. (Theoretically, no hard- 
ware or software is to be implemented until after 
the CDR, but in practice, system components are 
implemented early in the life cycle, often before 
the SDR, to test ideas and may be directly incor- 
porated or modified for the system as finally im- 
plemented.) At each of these reviews, designs are 
presented to a large audience with broad interests 
ensuring that system-level goals and requirements 
are addressed, user requirements are satisfied, and 
safety issues are adequately considered. The re- 
view boards provide detailed feedback to the sys- 
tem designers and implemented, and weaknesses 
or criticisms raised at a design review must be ad- 
dressed at the next level of review. 

The design review process is an iterative, and, 
one hopes, convergent process in which the goals 
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and requirements and functional specifications are 
interpreted and translated into a design specifica- 
tion that, among other things, establishes a par- 
titioning of functions between hardware and soft- 
ware. Design specifications for both hardware and 
software are translations of the functional speci- 
fications which in turn embody the system-level 
goals and requirements. The design specification 
is supported by an interface definition establish- 
ing both the interfaces between the system and its 
environment and the interfaces between the hard- 
ware and software. 

The design specifications are transformed into 
hardware and software realizations. This transfor- 
mation is not a straightforward, one-step process. 
The transformation of a design specification to an 
implemented prototype system requires the devel- 
opment and testing of numerous software proce- 
dures and hardware circuits, each of which is a 
prototype of some element in the larger system. 

The implementation of system elements or 
components is supported by a variety of analysis 
tools and testing techniques [1,2,4,12,13]. The 
analysis tools used include failure modes and ef- 
fects analysis, independent review, static verifica- 
tion, independent calculations, conjectures, and 
suspicions. This analysis is conducted on abstract 
models of the system or of the system compo- 
nents. Linear system models, aggregate system 
models, block diagrams, flow diagrams, schemat- 
ics, source programs, specifications, and simula- 
tions are some of the main abstract models used. 
This analysis of abstract models is used to trans- 
late requirement and design specifications into a 
physical realization. 

The physical realization of a system is con- 
structed from physical realizations of system com- 
ponents such as circuits, microprocessors, comput- 
ers, and software modules. Hardware components 
are often breadboard, brassboard, or nonflight- 
qualified versions of the actual flight system; these 
hardware components are bench tested in isolation 
and then incorporated into “hot-bench” test fa- 
cilities that incorporate other simulated or actual 
physical systems. Typical of these hot-bench test 
facilities are simulations incorporating flight hard- 
ware (hardware-in-the-loop simulations) [6, 7, 8] or 
iron bird facilities based on extensive replication 


of flight systems and are often based on the use of 
decommissioned aircraft [4]. 

Simulation testing provides a closed-loop fa- 
cility wherein the system is exposed to an envi- 
ronment that closely resembles the electronic and 
data environment in which the system must actu- 
ally operate. Simulation also provides a facility for 
testing that the hardware and software of the sys- 
tem are integrated and operating together. The 
realism of the simulation is determined by the op- 
erating requirements for the flight application of 
the system (see section 2.3). Simulation is where 
the pilot (the system user) is first exposed to and 
allowed to evaluate the system. 

This analysis, testing, and verification along 
with the configuration management process (see 
section 2.2) constitute main components of the 
qualification process wherein a system is deter- 
mined to be ready for flight test. These results 
are presented to a flight readiness review (FRR) 
team composed of nonproject engineers from mul- 
tiple engineering disciplines who perform an inde- 
pendent and in-depth review of the system design, 
analysis, test results, and configuration manage- 
ment. The FRR team is empowered to recom- 
mend additional analysis, testing, or documenta- 
tion. The results of the FRR are presented at 
an airworthiness and flight safety review (AFSR) 
panel where the project team seeking authoriza- 
tion for approval to begin flight testing responds 
to the findings of the FRR. The AFSR panel is 
typically composed of engineering and operations 
managers and flight safety personnel. Only after 
the AFSR is satisfied is a system taken to flight. 

Flight validation is an extension of the test- 
ing methods performed on physical models in the 
simulation. For a research system, the flight tested 
component is a physical model of itself; if the sys- 
tem is to be fielded in an operational environment, 
the flight tested system is often a prototype of the 
final system. During flight test, the system is ex- 
posed to the total physical, electronic, and data 
environment in which it is designed to operate. 

Gault and others [1], Holt and others [12], and 
Hopkins [13] propose the use of additional abstract 
models (aggregate models) and analysis methods 
(formal proofs and statistical analysis). These 
models and analysis tools address one of the chief 
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limitations in the Ames-Dryden methodology: the 
reliance on testing, both failure modes and effects 
and nominal condition testing. This becomes a se- 
rious concern when considering either highly reli- 
able, fault- tolerant systems or highly complex sys- 
tems. Hartmann and others [13] describe the num- 
ber of tests required for such systems as a funda- 
mental problem: 

The fundamental problem of fault toler- 
ance validation is the vast number of test 
cases when all possible combinations of 
flight conditions and multiple faults are 
considered. 

This view is confirmed by Gerhart and others [l], 
Holt and others [12], and Gerhart [15], who claim 
that exhaustive testing is not possible for any but 
the simplest of systems. 

2.2 Configuration Management 

Configuration management is the orderly and 
systematic process of ensuring consistency in de- 
velopment, documentation, testing, problem re- 
porting, and maintenance of a system. The use of 
a configuration control board (CCB) with review 
and change approval authority, consisting of repre- 
sentatives from several engineering disciplines, is 
a key feature of configuration management. Pe- 
tersen and Flores [16] describe the configuration 
management process: 

The primary purpose of the software 
control and system configuration man- 
agement process for flight-critical digi- 
tal flight control systems is to provide a 
method for efficient flight system devel- 
opment and a procedure for assuring safe 
flight operations. The process is designed 
to control system configuration changes 
by managing the primary system devel- 
opment phases . . . and to resolve dis- 
crepancies uncovered during system test- 
ing. In addition, the configuration con- 
trol process prescribes stringent test and 
documentation requirements and pro- 
vides for visibility of changes across all 
involved engineering disciplines through 
formal review procedures. 


Petersen and Flores [16] also present block dia- 
grams showing the steps in the software control 
and system configuration process (figure 2) and 
the documentation flow and tracking process (fig- 
ure 3) used at Ames-Dryden. This process is ini- 
tiated when the system is put under configuration 
control which is generally well into the system de- 
velopment cycle. 

Figure 2 shows how new system requirements 
or anomalous system behavior are accommodated 
in the software control and system configuration 
management process. New system requirements 
are introduced into the configuration manage- 
ment process using a configuration change request 
(CCR); anomalous system behavior is recorded on 
a discrepancy report (DR) (figure 3). 

The use of DRs to record any anomalous be- 
havior is useful for identifying and correcting prob- 
lems that result from operator error, initializa- 
tion, or system design. Additionally, the extensive 
use of DRs provides a means of isolating incipi- 
ent problems by identifying areas or functions in 
the system that are repeatedly involved in or as- 
sociated with anomalous behavior. Tracking DRs 
also facilitates one aspect of the process of build- 
ing confidence in the system (see section 2.1): it 
provides a means of judging the maturity of a sys- 
tem through experience with that system over an 
extended period. Typical experience with systems 
as a function of time is shown in figures 4 and 5. 

It is important to note that the problems 
identified in every DR cannot be or are not al- 
ways remedied. A problem that occurs in a test 
facility might be highly unlikely in flight; the sub- 
ject of a DR might even be based on a rethinking 
of the system design that uncovers a failure mode 
or potential problem. Program schedule slippage 
or the costs of fixing the problem are often over- 
riding concerns. The effect of problems identified 
in DRs is evaluated in terms of the risk associ- 
ated with them. Those known problems that are 
identified on DRs and not remedied are called “ac- 
cepted risks.” Accepted risks are always clearly 
identified before flight testing. The risks associ- 
ated with these problems are made visible to, and 
are evaluated by, independent reviewers such as 
those comprising the AFSR panel (see section 2.1). 
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Figure 3. Documentation Flow and Tracking Process 
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Figure 4 . F-8 DFBW Software- Anomaly Experience 


2.3 System Criticality and Its Impact 
on Validation 

The requirements imposed on the V&V and 
configuration management process are determined 
by the criticality of the system. For aircraft flight 
systems, three levels of criticality are generally 
recognized: 

A. Systems whose failure could cause loss of life 
or limb, compromise public safety, or result in 
substantial financial loss; 

B. Systems whose failure could cause mission 
failure (mission-critical); 

C. Systems whose failure could cause inaccurate 
results or inefficient use of resources. 

The level of criticality of a system is primarily de- 
termined by those requesting that the system be 
developed. However, system designers or any of 
the independent review teams can modify that de- 
termination. In practice, we have found that it is 


usually easier and less work to classify a system 
as a level B rather than try to support and de- 
fend a classification at level C. Nontechnical fac- 
tors are often taken into account when determin- 
ing at which level to class a system. A system 
might be treated at level A when that system or 
the project of which it is a part is highly visible 
and any perceived problem might jeopardize re- 
search goals. 

The configuration management process in- 
creases in formality at each higher level of criti- 
cality: the composition of the CCB is broader and 
consists of more members, the requirements for 
documentation increase, and testing requirements 
for system changes are more extensive. The re- 
quirements for the simulation also increase with 
higher levels of criticality: a level C system might 
be qualified off-line, using interactive or batch sim- 
ulations and stand-alone hardware tests; a level B 
system requires at least a real-time, piloted simu- 
lation for closed-loop testing; and a level A system 
generally requires a hardware-in-the-loop simula- 
tion or an iron bird. 
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3 APPLICATION OF 
VALIDATION 
METHODOLOGY TO 
KNOWLEDGE-BASED 
SYSTEMS 

The V&V methodology used for conven- 
tional, embedded operation- critical flight systems 
provides an established and accepted set of pro- 
cedures upon which a methodology for KBSs can 
be based. While this position may be controver- 
sial in the AI community, the political and socio- 
logical realities of flight research and testing will 
ultimately dictate that any methodology for the 
validation of KBSs at least address the currently 
used methodology for conventional systems. 

3.1 The Life Cycle Model for 
Knowledge- Based Systems 

The proposed approach to the V&V of KBSs 
relies on the life cycle model shown in figure 1. The 
life cycle model for a KBS has been a topic of con- 
siderable concern to some who have addressed the 
validation of a KBS, and several models have been 
proposed [17,18,19]. These models stress the de- 
velopment and prototyping process in a KBS. The 
motivation for developing these models is appar- 
ently to address the lack of a clear or well-defined 
statement of system goals and requirements and to 
highlight the prototyping process common in the 
development of KBSs. While the proponents of 
these models would probably contend that there 
is a fundamental difference between the life cycle 
of a KBS and a conventional system, another view 
is that this apparent difference is more reflective 
of the maturity of KBSs rather than of anything 
fundamental. 

Because KBSs are just emerging in operation- 
critical applications, there is little certainty of ca- 
pabilities and limitations of these systems. The 
prototyping that is a common feature in the de- 
velopment of a KBS often represents an attempt 
to establish requirements for a given application. 
This definition of requirements, capabilities, and 
limitations through prototyping is not unlike that 
used in conventional systems when new techniques 
or applications are attempted. The difference is 


in the body of knowledge and experience behind 
the use of conventional systems as opposed to that 
for KBSs. Also reflected in this prototyping is 
the lack of maturity of artificial intelligence (AI) 
techniques in general that provides little basis for 
the selection of control and knowledge representa- 
tion methods. 

3.2 Problems in the Verification and 
Validation of Knowledge-Based 
Systems 

There are several issues that are almost cer- 
tain to create problems for anyone attempting 
to validate operation-critical KBSs. Perhaps the 
most serious of these is an unwillingness to treat 
the current generation of KBSs out of the con- 
text of the promises of AI. The current generation 
of KBSs are not, in general, capable of learning 
or even modestly adaptive. These systems exhibit 
few nondeterministic properties. These KBSs may 
be complex but they are not unpredictable. But so 
long as there is this persistence in dwelling on the 
ultimate potential of AI systems instead of on the 
realities of the system being qualified, it is unlikely 
that an AFSR panel would allow flight testing. 

A further difficulty arises from the contention 
that KBSs do not always produce the correct an- 
swer. If this is true then a KBS can only be 
used for tasks in which their performance can 
be monitored and overridden by a human. Most 
operation-critical systems are required to perform 
without human intervention or with only high- 
level supervision or control. However, a KBS that 
does not always produce the optimum answer is 
acceptable as long as it never produces a wrong 
answer. This latter point is in fact one of the 
main V&V issues: operation-critical systems must 
be shown to always produce acceptable solutions. 

3.3 A Proposed Approach to De- 
velop a Verification and Valida- 
tion Methodology for Knowledge- 
Based Systems 

In order to validate a system, one must have 
a set of requirements for that system, and those 
requirements must establish the performance cri- 
teria and the limitations of the system. The ctir- 
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rent claim from some within the AI community 
that many of the characteristics of AI systems pre- 
clude such requirements either do not understand 
the validation issue or are unwilling to accept the 
structure and formalism required for validation. 
To address the issue of requirements, an incremen- 
tal approach to validating KBSs is needed. 

There are two key aspects of the proposed ap- 
proach to the V&V of KBSs: 

1. development of a KBS to perform some task 
that is well-known, well-understood, and for 
which conventional V&V techniques are ade- 
quate; and 

2. incrementally and simultaneously expand 
both the KBS and the V&V techniques to 
more demanding and complex tasks. 

The procedures used for verifying, qualifying, and 
validating conventional operation- critical flight 
systems at Ames- Dry den will be applied and mod- 
ified as required. Because we ultimately plan to 
carry these experiments to flight using the rapid- 
prototyping facility [20], this process will be per- 
formed under the aegis of the AFSR panel and 
will be under periodic review. The subject of this 
research will be a KBS that is being developed 
to perform aircraft maneuvers normally performed 
by highly trained pilots. 

The research plan is to identify maneuvers of 
increasing difficulty and to build gradually more 
complex and adaptive KBS to accomplish those 
maneuvers. This will include prototyping, evalu- 
ation, and a series of initial operating capabilities 


that will evolve into a sequence of documented 
requirements for testing against each version of 
the system. This approach fits well within the 
model of and practice used with conventional digi- 
tal systems. 

4 VALIDATING A SIMPLE 
KNOWLEDGE-BASED 
SYSTEM 

To illustrate the proposed approach to the 
V&V of KBSs, a rule-based longitudinal altitude- 
command autopilot example for an F-15 aircraft 
will be presented. The example presented repre- 
sents a single axis of a three-axis (longitudinal, 
lateral-directional, and velocity axes) controller. 
This controller is being developed and will be qual- 
ified as a mission-critical system (see section 2.3) 
as part of the research into validation methodolo- 
gies for operation-critical KBSs. 

4.1 Goals and Requirements for 
Example Knowledge-Based 
System 

A simplified representation of the aircraft and 
control system is shown in figure 6. The objective 
is to develop and to demonstrate a knowledge- 
based controller that produces command inputs 
to the aircraft control system based on a dynamic 
world model obtained from instruments on the air- 
craft and on a simple set of rules. While this task 
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Figure 6 . Simplified Longitudinal Model of the 
F-15 Aircraft and Its Control System 
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may not represent a suitable application of a KBS 
(because it is easily performed by conventional 
algorithmic control laws), it provides a simple 
mission- critical application that is both easy to 
understand and easy to validate. 

The control task requires the autopilot system 
(whether based on conventional algorithms or a 
knowledge-based approach) to produce commands 
that cause the measured aircraft altitude h to be 
within some specified tolerance Ah of the com- 
manded altitude h com . Additionally, constraints 
are placed on the altitude rate h and the nor- 
mal acceleration a n . The constraint on a n is the 
same as a constraint on altitude acceleration h , 
but a n represents a more easily understood and 
easily measured physical quantity. 

The initial requirement for this controller was 
that it control the aircraft in a consistent, repeat- 
able manner at least as well as a pilot during both 
the transition mode (going from one altitude to 
another) and the altitude-hold mode (controlling 
the aircraft about a specified altitude). The de- 
sire was to have it control the aircraft as well as a 
conventional algorithmic autopilot. An additional 
goal was to allow off- condition engagement so that 
the controller would be effective even without be- 
nign initial (engagement) conditions. 

These goals and requirements are similar to 
those initially imposed on the altitude-hold capa- 
bilities of the flight test maneuver autopilot for 
the HiMAT vehicle [21]. The constraints and tol- 
erances were established as baseline figures. From 
this initial specification, a rule-based system was 
implemented that combined numeric and symbolic 
methods. This initial system was tested using a 
detailed nonlinear simulation model of the aircraft 
and its control system; the controller achieved ex- 
cellent results for some initial conditions but per- 
formed poorly for many others. This initial result 
was typical of that experienced when evaluating 
the initial implementation of a conventional con- 
troller on a nonlinear simulation. After several it- 
erations of this process, a fairly detailed statement 
of performance capabilities and limitations was es- 
tablished (table I). This information, in essence, 
represents a clarification of the statement of goals 
and requirements, serves as the basis of a func- 
tional specification for the system, and defines the 


system test matrix. 

4.2 Life Cycle of Example Knowledge- 
Based System 

By this point in the life cycle, the develop- 
ment of a conventional controller would be sup- 
ported by design and analysis tools and abstract 
(linear) models of not only the aircraft and its con- 
trol system but of the controller as well. These 
tools and models would provide some of the basis 
of the validation of a conventional system by es- 
tablishing metrics of system performance and ro- 
bustness. The main benefit of having such tools 
and models is that their use allows extensive test- 
ing with a minimum of computational expense; 
only selected test points need to be repeated us- 
ing the nonlinear simulation. For the rule-based 
controller, tools and analysis techniques either do 
not exist or are rudimentary at best. This differ- 
ence in development will create some difficulties 
in qualifying the system for flight. Parts of the 
problem are both technical and sociological. Veri- 
fication will have to rely on more extensive testing 
and a thorough exposition of the nature of the 
rules. The testing will require that a large num- 
ber of tests be conducted on the nonlinear simula- 
tion that extends the time required for conducting 
those tests. 

Table I. System 
Performance Capabilities 
and Engagement Conditions 
Defined by Prototyping 


Performance requirements 

Ah 

= ± 50 ft 

hmax 

= ± 100 ft/sec 


= 2.0 g 

= 0.5 g 

Engagement conditions 

Ah 

= Too ft 

hmax 

= ± 200 ft/sec 

a n 

= ±2.0g 


The next step in the life cycle is an SDR. 
This has been conducted informally during de- 
velopment but now requires formal exposure and 
review. The rules derived from prototyping (ta- 
ble II) and a detailed definition of the verification 
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test matrix will be presented and reviewed at the 
SDR. Again, this addresses both the technical and 
sociological aspects of V&V: the SDR provides a 
technical assessment of the design, allowing the 
completeness and consistency of the rules to be 
examined by independent reviewers and serves as 
a gentle introduction to the idea of using KBSs in 
such applications. 

Table II. Rules for Longitudinal Altitude-Hold 
Autopilot 

Performance boundary rules* 

• If the altitude acceleration exceeds the 
positive acceleration limit, move stick 
forward. 

• If the altitude acceleration exceeds the 
negative acceleration limit, move stick aft. 

• If the predicted altitude rate exceeds the 
positive altitude rate limit, trim stick 
forward. 

• If the predicted altitude rate exceeds the 
negative altitude rate limit, trim stick aft. 

Normal command rules* 

• If the altitude error is positive and the 
predicted altitude rate is negative, trim 
stick aft. 

• If the altitude error is negative and the 
predicted altitude rate is positive, trim 
stick forward. 

• If the predicted altitude error is positive 
and the altitude error is small, click stick 
forward. 

• If the predicted altitude error is negative 
and the altitude error is small, click 

stick aft. 

• If the predicted altitude error is positive 
and the altitude error is large, trim 

stick forward. 

• If the predicted altitude error is negative 
and the altitude error is large, trim 

stick aft. 


*Definitions: 

move large movement of stick 
trim intermediate movement of stick 
click small movement of stick 

It is expected that the development of this 
rule-based controller will continue through the 
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normal life cycle for research systems. The main 
differences that are expected between conventional 
and KBSs are that for the KBS 

1. the design reviews will serve both educational 
and technical purposes; 

2. the design will incorporate more problem spe- 
cific experience (but probably less fundamen- 
tal system understanding) at each stage in the 
life cycle; 

3. the lack of traditional tools and abstract mod- 
els will force earlier recognition and definition 
of system testing requirements; and 

4. because of the lack of tools and abstract mod- 
els, the testing required for the rule-based 
system will be more extensive than that re- 
quired for a conventional system of similar 
capabilities. 

4.3 Test Matrix for Example 
Knowledge-Based System 

To appreciate the number of individual tests 
that must be performed as part of the validation 
of this longitudinal autopilot, two factors must be 
understood: 

1. the performance and limitations define a ma- 
trix of test conditions for each simulated flight 
condition; and, 

2. because the dynamics of an aircraft vary 
throughout its flight envelope, that matrix of 
test points must be repeated at many flight 
conditions. 

The performance requirements and engage- 
ment conditions define the requirements for both 
on- and off-condition operation. To test the on- 
condition requirements for the example autopilot, 
one engages the system at the test altitude and 
Mach number and monitors the performance of 
the system to ensure that none of the performance 
limits are exceeded. The testing of engagement 
requirements requires a set of tests about each of 
the altitude and Mach number points. Thus, for a 
given altitude and Mach number, the system must 
be engaged at a number of conditions representing 
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the permutations of the bounds of the engagement 
conditions; again, time histories are monitored to 
ensure that the system performs within the lim- 
its established by the performance requirements. 
At each altitude and Mach number test condition, 
this requires a minimum of eight separate tests. 

The dynamics of an aircraft are not constant 
throughout the flight envelope. To ensure that the 
system performance goals are met, tests must be 
performed at a number of flight conditions (fig- 
ure 7). At each altitude and Mach number con- 
dition, the entire matrix of performance require- 
ments must be tested at the engagement limits. 



Figure 7. Typical Flight Envelope With Ex- 
ample Test Conditions 

This testing is time consuming and requires 
a detailed nonlinear simulation. A conventional 
system would require less simulation testing on 
the nonlinear simulation because it would be sup- 
ported by abstract models of the aircraft and the 
autopilot. The nonlinear simulation would be used 
at a few selected altitude and Mach number con- 
ditions to verify the abstract models. 

It is important to note that the testing de- 
scribed above 

1. includes no failure condition testing, 

2. the example autopilot is a greatly simplified 
representation of a system that will be taken 
to flight, and 

3. the rules presented in table II represent only 
a single axis of a three-axis controller. 


5 LIMITATIONS OF 
VALIDATION 
METHODOLOGY FOR 
KNOWLEDGE-BASED 
SYSTEMS 

The most serious limitation of applying the 
V&V methodology for conventional systems to 
operation-critical KBSs is the lack of both struc- 
tured development methods and verification tools 
and techniques. Conventional systems are sup- 
ported by design and analysis tools and tech- 
niques, coding standards, and methods for exam- 
ining software that is procedural in nature. These 
tools, standards, and procedures do not exist for 
KBSs nor are any likely to emerge in the near 
term. Another limitation of applying the conven- 
tional V&V methodology to KBSs is that compo- 
nent testing is difficult if not impossible. Both of 
these limitations will force validation to rely on 
integrated system testing, treating the total KBS 
as a black box. 

The testing requirements for a system do not 
increase linearly with the complexity of the sys- 
tem; testing requirements grow as a polynomial 
or exponential function of system complexity. As 
a simple example of the growth of the test ma- 
trix with system complexity, consider the test ma- 
trix defined for the longitudinal autopilot (see sec- 
tion 4.3). A similar matrix would be defined for 
each axis of the total autopilot. If we assume that 
there are m tests required for each axis, then the 
final autopilot will have three axes of comparable 
complexity; the total number of tests will be m 3 
because all combinations of tests will have to be 
performed at each flight condition to validate the 
system performance. 

Testing any but the most simple systems as 
black boxes requires a test matrix of overwhelm- 
ing complexity. This will compound an already se- 
vere problem that has been a consistent factor in 
the V&V of conventional systems: the cost, sched- 
ule, and personnel requirements for V&V greatly 
exceed the development costs and almost always 
cause programmatic delays. Further, the costs and 
delays are directly related to how late, in the de- 
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velopment cycle, design and implementation errors 
are detected. 

One of the main challenges of developing a 
validation methodology for KBSs is to develop 
tools and techniques that will allow highly com- 
plex systems to be verified, qualified for flight, 
and validated in a cost-effective and timely man- 
ner without having to reduce the capability or 
operational envelope of that system. (This chal- 
lenge, incidentally, is one that those working with 
conventional systems must also face.) As part of 
the Ames-Dryden effort in developing and demon- 
strating a viable validation methodology for KBSs, 
the development of automatic testing systems is an 
integral part. The goal of this effort is to gener- 
ate test matrices automatically from requirements 
and specifications for use in an automated test- 
ing system capable of both conducting tests and 
monitoring and interpreting test results. 

6 CONCLUDING REMARKS 

The qualification, verification, and valida- 
tion methodology used at Ames-Dryden for flight- 
critical control systems and how this methodol- 
ogy can be extended and applied to intelligent 
knowledge- based systems are reviewed in this pa- 
per. The justification for the use of this method- 
ology is the similarity of the current generation 
of KBSs with conventional systems in terms of 
complexity and function. Limitations of the pro- 
posed methodology for both highly reliable, fault- 
tolerant systems and extremely complex systems 
such as might be envisioned for future generations 
of KBSs are discussed. Research and development 
areas are suggested to augment and enhance the 
current methodology to support both conventional 
systems as well as KBSs. 

The main differences between conventional 
systems and KBSs are that for the latter 

1. the design reviews will serve both educational 
and technical purposes, 

2. the design will incorporate more problem- 
specific experience (but probably less funda- 
mental system understanding) at each stage; 
in the life cycle, 


3. the lack of traditional tools and abstract mod- 
els will force earlier recognition and definition 
of system testing requirements, and 

4. because of the lack of tools and abstract mod- 
els, the testing required for the rule-based 
system will be more extensive than that re- 
quired for a conventional system of similar 
capabilities. 

The view presented in this paper is consistent 
with that proposed in Gault and others [1]: 

A validation methodology for such sys- 
tems [ultrahigh reliability, fault-tolerant 
systems] must be based on a judicious 
combination of logical proofs, analytical 
modeling, and experimental testing. 

This methodology must be supported by reliable, 
validated development and test tools that lower 
the cost and reduce the schedule, if the goal of val- 
idation is to be achieved for either highly reliable, 
fault-tolerant systems or highly complex systems 
such as are envisioned for KBSs. 

Perhaps the biggest obstacle in the qualifica- 
tion of operation-critical KBSs is the mystification 
and obfuscation by the advocates and developers 
of KBSs. While stressing the enormous differences 
between KBSs and conventional systems may be 
a useful tactic in generating enthusiasm and sup- 
port for the development and use of KBSs, this 
approach is almost guaranteed to discourage ac- 
ceptance and prevent deployment of these systems 
in operation-critical applications. 
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